1. Field of the Invention
The present invention relates to graphical systems for creating and executing data flow programs, and more specifically to a method and apparatus for providing attribute nodes in a graphical data flow environment.
2. Description of the Related Art
A computer system can be envisioned as having a number of levels of complexity. Referring now to FIG. 1, the lowest level of a computer system may be referred to as the digital logic level. The digital logic level comprises the computer's true hardware, primarily consisting of gates which are integrated together to form various integrated circuits. Other hardware devices include printed circuit boards, the power supply, memory, and the various input/output devices, among others. Gates are digital elements having one or more digital inputs, signals representing 0 or 1 states, and which compute an output based on these inputs according to a simple function. Common examples of gates are AND gates, OR gates, etc. It is also noted that there is yet another level below level 0 which can be referred to as the device level. This level deals with the individual transistors and semiconductor physics necessary to construct the gates comprising the digital logic level.
The next level, referred to as level 1, is referred to as the microprogramming level. The microprogramming level is essentially a hybrid between computer hardware and software. The microprogramming level is typically implemented by software instructions stored in ROM (read only memory), these instructions being referred to as microcode. The microprogramming level can be thought of as including various interpreters comprised of sequences of microcode which carry out instructions available at the machine language level, which is at level 2. For example, when an instruction such as an arithmetic or shift function appears at the machine language level, this instruction is carried out one step at a time by an interpreter at the microprogramming level. Because the architecture of the microprogramming level is defined by hardware, it is a very difficult level in which to program. Timing considerations are frequently very important in programming at this level and thus usually only very skilled, experienced microprogrammers operate at this level.
As mentioned above, the level above the microprogramming level is referred to as the machine language level. The machine language level comprises the 1's and 0's that a program uses to execute instructions and manipulate data. The next level above the machine language level is referred to as the assembly language level. This level includes the instruction set of the computer system, i.e. the various op codes, instruction formats, etc. that cause the computer to execute instructions. In assembly language each instruction produces exactly one machine language instruction. Thus, there is a one to one correspondence between assembly language instructions and machine language instructions. The primary difference is that assembly language uses very symbolic human-readable names and addresses instead of binary ones to allow easier programming. For example, where a machine language instruction might include the sequence "101101," the assembly language equivalent might be "ADD." Therefore, assembly language is typically the lowest level language used by programmers, and assembly language programming requires a skilled and experienced programmer.
The next level includes high level text-based programming languages which are typically used by programmers in writing applications programs. Many different high level programming languages exist, including BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL, etc. Programs written in these high level languages are translated to the machine language level by translators known as compilers. The high level programming languages in this level, as well as the assembly language level, are referred to in this disclosure as text-based programming environments.
Increasingly computers are required to be used and programmed by those who are not highly trained in computer programming techniques. When traditional text-based programming environments are used, the user's programming skills and ability to interact with the computer system often become a limiting factor in the achievement of optimal utilization of the computer system.
There are numerous subtle complexities which a user must master before he can efficiently program a computer system in a text-based environment. For example, text-based programming environments have traditionally used a number of programs to accomplish a given task. Each program in turn often comprises one or more subroutines. Software systems typically coordinate activity between multiple programs, and each program typically coordinates activity between multiple subroutines. However, in a text-based environment, techniques for coordinating multiple programs generally differ from techniques for coordinating multiple subroutines. Furthermore, since programs ordinarily can stand alone while subroutines usually cannot in a text-based environment, techniques for linking programs to a software system generally differ from techniques for linking subroutines to a program. Complexities such as these often make it difficult for a user who is not a specialist in computer programming to efficiently program a computer system in a text-based environment.
The task of programming a computer system to model a process often is further complicated by the fact that a sequence of mathematical formulas, mathematical steps or other procedures customarily used to conceptually model a process often does not closely correspond to the traditional text-based programming techniques used to program a computer system to model such a process. For example, a computer programmer typically develops a conceptual model for a physical system which can be partitioned into functional blocks, each of which corresponds to actual systems or subsystems. Computer systems, however, ordinarily do not actually compute in accordance with such conceptualized functional blocks. Instead, they often utilize calls to various subroutines and the retrieval of data from different memory storage locations to implement a procedure which could be conceptualized by a user in terms of a functional block. In other words, the requirement that a user program in a text-based programming environment places a level of abstraction between the user's conceptualization of the solution and the implementation of a method that accomplishes this solution in a computer program. Thus, a user often must substantially master different skills in order to both conceptually model a system and then to program a computer to model that system. Since a user often is not fully proficient in techniques for programming a computer system in a text-based environment to implement his model, the efficiency with which the computer system can be utilized to perform such modeling often is reduced.
One particular field in which computer systems are employed to model physical systems is the field of instrumentation. An instrument is a device which collects information from an environment and displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others. An instrumentation system ordinarily controls its constituent instruments from which it acquires data which it analyzes, stores and presents to a user of the system. Computer control of instrumentation has become increasingly desirable in view of the increasing complexity and variety of instruments available for use.
In the past, many instrumentation systems comprised individual instruments physically interconnected. Each instrument typically included a physical front panel with its own peculiar combination of indicators, knobs, or switches. A user generally had to understand and manipulate individual controls for each instrument and record readings from an array of indicators. Acquisition and analysis of data in such instrumentation systems was tedious and error prone. An incremental improvement in the manner in which a user interfaced with various instruments was made with the introduction of centralized control panels. In these improved systems, individual instruments were wired to a control panel, and the individual knobs, indicators or switches of each front panel were either preset or were selected to be presented on a common front panel.
A significant advance occurred with the introduction of computers to provide more flexible means for interfacing instruments with a user. In such computerized instrumentation systems the user interacted with a software program executing on the computer system through the video monitor rather than through a manually operated front panel. These earlier improved instrumentation systems provided significant performance efficiencies over earlier systems for linking and controlling test instruments.
However, these improved instrumentation systems had significant drawbacks. For example, due to the wide variety of possible testing situations and environments, and also the wide array of instruments available, it was often necessary for a user to develop a program to control the new instrumentation system desired. As discussed above, computer programs used to control such improved instrumentation systems had to be written in conventional text-based programming languages such as, for example, assembly language, C, FORTRAN, BASIC, or Pascal. Traditional users of instrumentation systems, however, often were not highly trained in programming techniques and, in addition, traditional text-based programming languages were not sufficiently intuitive to allow users to use these languages without training. Therefore, implementation of such systems frequently required the involvement of a programmer to write software for control and analysis of instrumentation data. Thus, development and maintenance of the software elements in these instrumentation systems often proved to be difficult.
U.S. Pat. No. 4,901,221 to Kodosky et al discloses a graphical system and method for modeling a process, i.e. a graphical programming environment which enables a user to easily and intuitively model a process. The graphical programming environment disclosed in Kodosky et al can be considered the highest and most intuitive way in which to interact with a computer. Referring now to FIG. 1A, a graphically based programming environment can be represented at level 5 above text-based high level programming languages such as C, Pascal, etc. The method disclosed in Kodosky et al allows a user to construct a diagram using a block diagram editor such that the diagram created graphically displays a procedure or method for accomplishing a certain result, such as manipulating one or more input variables to produce one or more output variables. As the user constructs the data flow diagram using the block diagram editor, machine language instructions are automatically constructed which characterize an execution procedure which corresponds to the displayed procedure. Therefore, a user can create a text-based computer program solely by using a graphically based programming environment. This graphically based programming environment may be used for creating virtual instrumentation systems and modeling processes as well as for any type of general programming.
Therefore, Kodosky et al teaches a graphical programming environment wherein a user manipulates icons in a block diagram using a block diagram editor to create a data flow "program" or virtual instrument (VI). In creating a virtual instrument, a user first creates a front panel including various controls or indicators that represent the respective input and output that will be used by the VI. When the controls and indicators are created in the front panel, corresponding icons or terminals are automatically created in the block diagram by the block diagram editor. The user then chooses various functions that accomplish his desired result, connecting the corresponding function icons between the terminals of the respective controls and indicators. In other words, the user creates a data flow program, referred to as a block diagram, representing the graphical data flow which accomplishes his desired function. This is done by wiring up the various function icons between the control icons and indicator icons. The manipulation and organization of icons in turn produces machine language that accomplishes the desired method or process as shown in the block diagram. A user then optionally chooses a connector pane representing the input and output terminals corresponding to the respective controls and indicators already created.
Once the controls and indicators have been placed on the front panel and a connector pane has been selected, a user will then associate respective terminals on the connector pane to the respective controls and indicators on the front panel. For example, if a connector pane having three terminals has been selected, and two controls and one indicator are created on the front panel, the user can designate respective terminals on the connector pane to correspond to the respective controls and indicators on the front panel.
A user inputs data to a virtual instrument using front panel controls. This input data propagates through the data flow block diagram or graphical program and appears as changes on the output indicators. The data that flows from the controls to the indicators in this manner is referred to as control data. In an instrumentation application, the front panel can be analogized to the front panel of an instrument. The user adjusts the controls on the front panel to affect the input and views the output on the respective indicators.
While a user could adjust the input to the virtual instrument using controls on the front panel and view the corresponding change in output on indicators on the front panel, the user could not affect any other changes to the front panel during execution. For example, the user often desired to change the appearance of a control, i.e. write to a control, on the front panel during execution of a program to provide a more meaningful and more intuitive visual display. For example, it would be highly desirable that the user be able to move cursors on a graph to select points as input to further parts of the block diagram. It would also be desirable for a data flow program or block diagram to have the ability to programmatically change the appearance of a control or write to a control during execution. For example, the user may want the block diagram to automatically change the display colors on an indicator depending on whether a certain output is above or below a certain level. One example of this is where the user wants the output of an indicator to show up in green if a given process being modelled is running in a normal manner and show up in red if the process is operating at undesirable levels. The user may also want to be able to program the block diagram to automatically hide certain controls or indicators when they are not in use.
In the method and apparatus described in Kodosky et al., it was not possible for the user to programmatically control the appearance of the front panel during execution other than control data that appeared as conventional output data. Therefore, a method and apparatus is desired to enable a user to set and read various attributes which affect the appearance of controls on a front panel programmatically and can also enable the user to provide interactive input that can be read by a block diagram as it is executing.